This fails here and on master, but I wonder if it needs to?

@x & (a | b) => c

$ cylc val .
WorkflowConfigError: Xtriggers cannot be used in conditional graph expressions:
@x&(a:succeeded|b:succeeded) => c

It's been a long time since I looked at - and probably wrote - the associated code, so I'm not sure of the reason for the restriction anymore, and whether it should apply to this sort of expression (and I'm out of time today). But possibly it should not fail because it's equivalent to this:

@x => c
a | b => c

This fails here and on master, but I wonder if it needs to?

If this PR isn't changing behaviour, suggest moving this to another issue. Opened #6949.

As Hillary pointed out, there is already logic intended to catch xtriggers used in conditional expressions:

However, this check isn't catching situations where there are no tasks on the LHS, only xtriggers.

Sidenote: Strangely, this code is in cylc.flow.validate (which means you can bypass this error using cylc install; cylc play). I suspect this is purely historical, this should really be in cylc.flow.config.

If the new test covers all of the logic of the old one, suggest ripping the old check out. There are probably tests for the old check which could do with being combined / erased.

I ran a bunch of our workflows through cylc validate on this branch, no spurious failures :)

However, beyond @wall_clock xtriggers are not used at our site, might be worth getting Hillary to make sure it doesn't cause any false positives with NIWA workflows?

However, beyond @wall_clock xtriggers are not used at our site, might be worth getting Hillary to make sure it doesn't cause any false positives with NIWA workflows?

Unfortunately, due to enforced home dir privacy here, I can't see our workflows.

@wxtim, I think the reason you drafted this is that there is already code that is supposed to detect this scenario, but it's not working right, see #6772 (comment).

We only need one check, but would like it to cover all bases.

Removing (or fixing) the other check would probably resolve the situation where this expression is failing validation:

@x & (a | b) => c

Not strictly the job of this PR, but these two approaches have to be rationalised anyway (see #6772 (comment))

If the new test covers all of the logic of the old one, suggest ripping the old check out.

Done that

There are probably tests for the old check which could do with being combined / erased.

I couldn't find any and nothing failed when I took it out.
🤣🤣🤣🤣

I have added a unit test for some of the remaining untested stuff. I'm not entirely convinced that it's reachable.